This PR currently updates the templates so that when WebAssembly is the only enabled interactive render mode, the Weather page uses WebAssembly interactivity with prerendering disabled. The interactive version of the Weather page makes an HTTP request to fetch weather forecast data upon component initialization.

This has some limitations:

• There's a period where content on the Weather page is "blank", and this period is particularly long if the Weather page is the first interactive page navigated to. This is expected as a natural consequence of disabling prerendering, but it doesn't look good (especially since there's no loading text, since that's also rendered interactively).
  • This is even worse with top-level interactivity, because then you just get a blank screen while WebAssembly initializes. We could address this by re-introducing the loading indicator when top-level interactivity is used with WebAssembly.
• It doesn't demonstrate how to solve the problem when using the Auto render mode.

We could alternatively:

• Introduce an IWeatherForecast interface with implementations on the server and the client
• Inject that service into the existing Weather page
• If WebAssembly interactivity is enabled, place the Weather page in the client project
• If any interactivity option is enabled, add a check to make sure we're interactive before fetching data (to avoid the double-fetching issue):

  if (RendererInfo.IsInteractive)
  {
    forecasts = weatherForecast.GetWeatherForecastAsync();
  }

While it solves the issues I described above, it does introduce a tad bit more complexity into the template. However, it's closer to what I believe we'd recommend for a real, production-quality app.

An even better long term solution would be to utilize #51584 when it gets implemented, but that may happen after the template changes for .NET 9 have been locked down.

Thoughts?

cc @dotnet/aspnet-blazor-eng